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This memo describes changes to the Mesa language and compiler that have been made since 
the last release (October 17, 1977). As usual, the list of compiler-related change requests 
closed by Mesa 4.0 will appear separately as part of the Software Release Description. 

The language accepted by the Mesa 4.0 compiler has several significant extensions and a few 
minor changes. It features a process mechanism, enhanced arithmetic capabilities, long and 
base-relative pointers, and more general block structure. 

Because of changes in symbol table and BCD formats, all existing Mesa programs must be 
recompiled. There are minor incompatibilities with Mesa 3.0 at the source level in the areas 
of signed/unsigned arithmetic and the scope of open in an iterative statement. These 
incompatibilities should have negligible impact on existing programs. The syntax and 
semantics of declaring (but not calling) machine-coded procedures have changed 
substantially. 

Page and section numbers in this update not otherwise qualified refer to the Mesa Language 
Manual, Version 3.0. The BNF descriptions of new or revised syntax follow the 
conventions introduced in that manual. For phrase classes used but not redefined here, see 
its Appendix D. Revisions of phrase class definitions are cumulative; except as noted, the 
appearance of as an alternative indicates that an existing definition is being augmented. 
A definition without supersedes any definition of the same phrase class in the manual. 



Mesa 4.0 supports double-precision integer arithmetic (type long integer) and provides 
some help with floating-point computations (type real). In conjunction with these changes, 
the rules governing combination of signed and unsigned values have been more carefully 
defined (see the Appendix to this memo). 



Arithmetic 



Syntax 



PredefinedType ::= 



INTEGER I CARDINAL | LONG INTEGER | REAL | 
boolean I CHARACTER | STRING | UNSPECIFIED | WORD 



Primary ... | identifier [ Expression ] | long [ Expression ] 
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Signed and Unsigned Arithmetic 

The rules governing the use of signed and unsigned representations in single-precision 
arithmetic have been reformulated. In previous versions of Mesa, conditions under which 
an operation was considered to overflow were not well defined. As a consequence, options 
such as overflow detection and reliable range checking were precluded. Mesa 4.0 does not 
offer these options, but it does remedy the defects in the language definition. 

The precise rules governing signed/unsigned arithmetic are somewhat lengthy. They appear 
in an appendix to this memo with some background information explaining the motivation 
and philosophy. In their effect on the acceptance or rejection of source text, the new rules 
differ little from those in previous versions of Mesa; the main change is that cardinal - 
CARDINAL is now assumed to produce a result with unsigned (instead of unknown) 
representation (see Section 2.5.1, pages 10-12). Thus the immediate practical effect of the 
new rules is minor; however, programmers should read the appendix carefully so that their 
code will work correctly even when it becomes possible to request overflow and range 
checks. 

The effects of the new rules with respect to subtraction are worth emphasizing. If 
both operands have valid signed representations, the result is an integer. If both 
have only unsigned representations, the result is a cardinal and is considered to 
overflow if the first operand is less than the second. 

/; integer; m, n: cardinal; s, t: [0..10); 

/ ^ m-n; should be used only if it is known that m >^ n 

i ^ w m>^ n then m-n else "(n-m); should be used otherwise 

IF m-n > 0 ... comparison (and subtraction) are unsigned 

\Fm>n... --a better and safer test 

IF 5-/ < 0 ... comparison (and subtraction) are signed 

Range Assertions 

The new rules mentioned above assume that there are implicit conversion functions mapping 
cardinal to INTEGER and vice-versa. In both directions, the "conversion" amounts to an 
assertion that the argument is an element of integer n cardinal The programmer can 
make such a range assertion explicit. If S is an identifier of a subrange type and e is an 
expression with compatible type T, the form 5[e] has the same value as e and is 
additionally an assertion that e in [FiRST[5nr] .. LAST[5nr]] is true. 

Note that this is not equivalent to L0OPH0LE[e, S] but is an assertion about the range 
of a value that already has an appropriate type. 

In Mesa 4.0, such assertions must be verified by the programmer. There is not an option to 
generate code that checks these assertions, whether implicit or explicit. An assertion can be 
used to control the assumed representation of a subexpression; otherwise, it is currently 
treated as a comment by the compiler. 

Examples 

integer[ai], IndexTypeli-J} 
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Long Integers 

Mesa 4.0 supports double-precision integers. There is a new predeclared type long integer, 
values of which occupy two words (32 bits) of storage and range over [-2^-^ 2-^^). There is 
no special denotation for long integer constants. The type of any decimal or octal constant 
in [2^^ .. 2^^) is long integer; smaller constants are converted as required by context. The 
arithmetic operators +, *, /, mod, min, max, (unary) - and abs have double-precision 
extensions that perform the mapping 

(long integer)" long integer; 

furthermore, long integers are ordered, and the relational operators =, #, <,<=,>,>= and in 
have extensions that perform the mapping 

(long integer)" boolean. 
Some fine points: 

All LONG INTEGERS have a signed representation; the Mesa 4.0 language does not 
provide long cardinal. 

Addition, subtraction, and comparison of long integers is fast; multiplication and 
division are done by software and are relatively slow. 

In Mesa 4.0, it is not possible to declare a type that is a subrange of long integer. 

Mesa provides an automatic coercion from any single-precision numeric type (integer, 
cardinal, etc.) to long integer. This coercion is called widening and is discussed in more 
detail below. It is applied when necessary to match inherent and target types (e.g., in 
assignments). Also, if any operand of an arithmetic or relational operator is a long integer, 
the double-precision operation is used. In most cases, widening of any shorter operands is 
automatic. Thus single- and double-precision quantities can be mixed freely within 
expressions to yield double-precision results. 

The form LONG[e] explicitly forces the widening of any expression e with a single-precision 
numeric type. There are no automatic conversions from long integer to any single- 
precision type (but see the Mesa 4.0 System Documentation for some standard procedures). 

Widening of a single-precision constant is done at compile-time. Currently, no 

other arithmetic or relational operations on long integers are performed at 
compile-time, even if all operands are constant. 

Widening of a single-precision expression is substantially more efficient if that 
expression has an unsigned representation. 

Examples 

i: integer; 

//; LONG integer; 

c2: LONG integer = 2; — a compile-time constant 

c4: LONG INTEGER = c2*c2; -- not a compile-time constant 

// ^ 0; // ^ //+1; // ^ /; // {ii+i)/c2; — all valid 

// ^ long[0]; // ^ (//+long[/])/c2; — also valid (and explicit) 

/ <- //; // <- loinig[c^]; — invalid 
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Reals 

A standard representation for floating-point values has not yet been chosen. Mesa 4.0 
nevertheless provides some help with floating-point computation. It allows declaration and 
assignment of real values; furthermore, real expressions constructed using the standard 
infix operators (except mod) are converted to sequences of procedure calls by the compiler, 

A REAL value is assumed to occupy two words (32 bits) of storage. Beyond this, no 
assumptions are made about the representation of reals. Users of real arithmetic must 
provide and install an appropriate set of procedures for performing the arithmetic 
operations (see the Mesa 4,0 System Documentation also). The procedures must be 
assignable to variables declared as follows: 

FADD, FSUB, FMUL, FDIV: procedure [real, real] returns [real]; 

FCOMF: PROCEDURE [real, real] returns [integer]; 

returns a value that is: 0 if equal, negative if the first is less, positive otherwise 

FLOAT: procedure [long integer] returns [real]; 

This scheme has the following consequences: 

All other arithmetic operations (abs, min, etc.) are fabricated from these primitives. 

The source language provides no denotation for real constants, since the compiler 
does not know the internal format expected by the user-supplied procedures. As 
discussed below, values of type integer or long integer are automatically converted 
to type real at run -time; thus integer constants can appear in real expressions but 
will be reconverted each time the expression is evaluated. 

Of course, implementers of floating-point packages are free to provide their own procedures 
for constructing real values from, e.g., octal constants, but a real "constant" currently 
cannot be a compile-time constant and cannot appear in a definitions module (unless it is 
defined using a loophole). 

Examples 

Two: REAL = 2; — means Two: real = FLOATllln 

Half: real = l/Two; — means Half: real = FLOATliyTwo; 

Bug: REAL = 1/2; — means Bug: real = FLOATIO']; (integer division) 

Implicit Conversions 

Conversions from integer or cardinal to long integer and from long integer to real are 
called widening. Widening is automatic in the following situations: 

An expression will be widened from its inherent type to match its target type (see 
Section 3.5, pages 37-39). This occurs in assignments and assignment-like contexts 
(such as record construction or extraction). 

The types of the operands of an arithmetic operator will be balanced by widening 
until all match the type of the widest operand (but not further, even if the target 
type is wider). 

In Mesa 4.0, automatic widening is not completely implemented in the following situations: 

Operands of min and max will be widened to match the target type if one is well 
defined and otherwise to match the type of the first operand, but there is no general 
balancing. 
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The endpoints in the right operand of in will be widened to match the type of the 
left operand, but there is no general balancing. 

Expressions appearing in the arms of conditionals will be widened as required by the 
target type, but there is no general balancing when the target type is ill-defined. 

The expressions selecting the arms of a SelectExpr or SelectStmt will be widened to 
match the type of the selector, but the selector itself is never widened. 

The following examples illustrate widening. 

/, j: integer; long integer; x: real; 

// ^ /; X <- /; X ^ ii\ x ^ w i < j then / else // 

/ + //, // + 1 — added as long integers (for any target type) 

/ + X, X + 1, // + X — added as reals 

x > /*y + // — multiplied as integers, added as long integers, compared as reals 

The following are currently considered errors. 
a IN [i .. x) 

(if / < ; then / ELSE //) < X — ill-defined target for IfExpr 

SELECT / FROM X => ...; > // => ...; ENDCASE 

In cases in which automatic widening is not implemented or does not give the desired result, 
the operator long or user-supplied procedure FLOAT can be used. 

m, n: cardinal; //; long integer; 

a ^ m •¥ n — added as cardinals (overflow lost) 

// long[/72 + n\ — ditto 

// ^ LONG[m] + long[a2] — added as long integers (overflow captured) 

A fine point: There are system-provided procedures for performing certain 
multiplication and division operations in which the operands and results do not all 
have the same precision. These procedures provide less expensive equivalents of, e.g., 
L0NG[m]*L0NG[A2]. See the Mesa 4.0 System Documentation. 



Long Pointers and Array Descriptors 



Mesa 4.0 implements both long pointers and array descriptors with long pointers as base 
components. These pointers provide access to the entire virtual memory of the Dstar. For 
compatibility, long pointers are also supported on the Alto, but they do not provide any 
additional addressing capability. 

Syntax 

TypeConstructor ... | LongTC 

LongTC long TypeSpecification 

ArrayDescriptorTC ::= descriptor for TypeSpecification | 

descriptor for PacklngOption array of TypeSpecification 
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The type constructor long can be applied to integer (discussed in the preceding section), 
any pointer type, or any array descriptor type. An attempt to lengthen any other type is an 
error. 

The type constructor descriptor for can be applied to any array type, including one 
designated by a type identifier. (This corrects an oversight in previous versions of Mesa). 
In addition, specification of an IndexType for the described array type can be omitted if its 
constructor follows immediately. In this case, a subrange of cardinal with zero origin and 
indefinite upper bound is assumed for the index type. 

Long Pointers 

A long pointer value occupies two words (32 bits) of storage. Long pointers are typically 
created by lengthening (short) pointers as described below. In particular, nil is automatically 
lengthened to provide a null long pointer when required by context. The standard 
operations on pointers (dereferencing, assignment, testing equality, comparison if ordered, 
etc.) all extend to long pointers 

On the Dstar, nil is lengthened by prefixing a word of zeros and thus has an MDS- 
independent representation. All other pointers are lengthened by adding the MDS 
base. Every pointer generated in this way is represented by an 8 bit field of zeros 
followed by a 24 bit virtual address. Long pointers with certain other formats can 
be created using loophole and will be correctly dereferenced by the hardware. 
There is no normalization prior to operations on pointers, however, and such 
pointers will give anomolous results in, e.g., comparisons. 

On the Alto, pointers are lengthened by prefixing a word of zeros. In all 
dereferencing operations, that prefix is discarded (without a check for zero) and the 
remaining word is interpreted as the actual address. 

Both automatic widening and explicit widening (using the operator long) are provided for 
pointer types as well as for numeric types. Widening an expression of type pointer to T 
produces a value of type long pointer to T, i.e., only the length attribute is changed by the 
widening. The rules and restrictions governing widening in Mesa 4.0 that are discussed in 
the preceding section apply equally to pointers. 

The operator @ applied to a variable of type T produces a pointer of type long pointer to 
T if the access path to that variable itself involves a long pointer (other than the implicitly 
accessed MDS pointer) and of type pointer to T otherwise. 

Limited pointer arithmetic continues to be supported Jn Mesa 4.0, but programmers are 
encouraged to use base and relative pointers (described in the next section) if the purpose 
of the arithmetic is simple relocation. If either operand in a pointer addition or subtraction 
is long, all operands are widened and the result is long. 

Examples 

R: TYPE = RECORD [/.* T, ...]; 

p, q: POINTER TO R\ 

pp, qq: LONG POINTER TO R\ 

pT: POINTER TO T\ 

ppT: LONG POINTER TO T\ 

The following are valid. 
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PP ^ 99; PP ^ nil; pp ^ p 

PP = 99» PP = NIL, = ? — long comparisons 

pT ^ @p.f\ ppT ^ @pp.f 

ppT ^ @p.f — pointer lengthened 

pp-^ii, pp-^is p-^ii, pp-qq, pp^q long results 



The following are not valid. 
PP = PpT 

p ^ ppi pT ^ @pp/ 



- type clash 

- no automatic shortening 



Long Array Descriptors 

In a long array descriptor, the base component is a long pointer and the descriptor occupies 
three words (48 bits) of storage. All the standard operations on array descriptors (indexing, 
assignment, testing equality, length, etc.) extend to long array descriptors. The type of 
BASE[afe5c] is long if the type of desc is long. 

Array descriptors are widened, either automatically or explicitly, according to the usual rules 
and restrictions. Long array descriptors are created by applying DESCRiPTOR[] to an array 
that is only accessible through a long pointer (other than the MDS pointer), by applying 
descriptor[„] to operands the first of which is long, or by widening a (short) array 
descriptor. 

Examples 

d: DESCRIPTOR FOR ARRAY OF T\ 

dd: LONG DESCRIPTOR FOR ARRAY OF T\ 

/, n: cardinal; 

pp: LONG pointer to array [0..0) OF jT; 
x: T\ 

dd <- descriptorOp, 10, r]; dd ^ d 
X ^ ddlil 

PP <r BASE[rf<i]; n LENGTH[rfi/] 

Base and Relative Pointers 

Mesa 4.0 deals more satisfactorily with base-relative pointers, i.e., pointers that must be 
relocated by adding some base value before they are dereferenced. Such pointers are useful 
for reducing the number of bits stored when objects can be identified by small offsets, and 
for dealing with collections of interlinked data items that are subject to relocation as entire 
aggregates. 



Syntax 



PointerTC ::= Ordered BaseOption pointer Optionallnterval PointerTail 
BaseOption ::= empty | base 
TypeConstructor ... | RelativeTC 
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RelativeTC ::= Typeldentifier relative TypeSpecification 

In a PointerTC, a nonempty Optionallnterval declares a subrange of a pointer type, the values 

of which are restricted to the indicated interval (and can potentially be stored in smaller 
fields). Normally, such a subrange type should be used only in constructing a relative 
pointer type as described below, since its values cannot span an MDS. 

The BaseOption base indicates that pointer values of that type can be used to relocate 
relative pointers. Such values behave as ordinary pointers in all other respects with one 
exception: subscript brackets never force implicit dereferencing (see below). The attribute 
BASE is ignored in determining the assignability of pointer types. 

A RelativeTC constructs a relative pointer or relative array descriptor type. The 
Typeldentifier must evaluate to some (possibly long) pointer type which is the type of the 
base, and the TypeSpecification must evaluate to a (possibly long) pointer or array descriptor 
type. 

Note that the form 

LONG Typeldentifier relative TypeSpecification 

is always in error, since long cannot be applied to a relative type. The type 
designated by the TypeSpecification can be lengthened (to give a relative long 
pointer) using the form 

Typeldentifier relative long TypeSpecification . 

Relative Pointers 

In the following discussion, assume the declarations 

BaseType: type = base pointer to 

FullType: type = pointer to 

RelativeType: type = BaseType relative FullType; 

base: BaseType; 

offset: RelativeType; 

p: FullType. 

If FullType is some pointer, long pointer, or pointer subrange type, RelativeType is declared 
to be a relative pointer type. Values with type RelativeType are pointers that must be 
relocated, by adding some value of type BaseType, before they can be dereferenced. Also, 
relative pointers are never widened automatically. With respect to other operations 
(assignment, testing equality, comparison if FullType is ordered, etc.), relative pointers 
behave like pointers of type FullType. In particular, the amount of storage required to store 
such a pointer is determined by FullType. Note, however, that RelativeType and FullType 
are distinct types, incompatible with respect to, e.g., assignment and comparison. 

Relocation of a relative pointer is specified by using subscript-like notation in which the 
type of the "array" is BaseType and that of the "index" is RelativeType, i.e., the absolute 
pointer is denoted by an expression with the form 

baseloffset} 

This expression has the type FullType and the value LOOP\~\OLE[ba se']+off set. Note that 
baseloffset'] is not a variable; typical variable designators are baseloffset^"^ or 
baseloffsetJi/ield, (In addition, the usual rules for implicit dereferencing apply in, e.g., an 
Openltem). Relocation prior to dereferencing is mandatory; offsetf, offset.field, etc. are 
errors. 
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Some fine points: 

The type of basel^offsetl is more precisely defined as follows: if FullType is a 
subrange pointer type, the subrange is discarded to obtain some type T\ otherwise, T 
is FullType. If FullType is not a long pointer type but BaseType is, then the final 
type is LONG T\ otherwise, it is T. In other words, the resulting type is long if either 
the base type or the relative type is. 

The declaration of a relative pointer does not associate a particular base value with 
that pointer, only a basing type. Thus some care is necessary if multiple base values 
are in use. Note that the final type of the relocated pointer is largely independent of 
the type of the base pointer; the relative pointer determines the type. Sometimes this 
observation can be used to help distinguish different classes of base values without 
producing relocated pointers with incompatible types. 

The base type must have the attribute base. Conversely, the attribute base always 
takes precedence in the interpretation of brackets following a pointer expression. 
Consider the following declarations: 

p: POINTER TO ARRAY IndexType OF 

q: BASE POINTER TO ARRAY IndexType OF ... . 

The expression ple^ will cause implicit dereferencing of p and is equivalent to 
j[?t[e3. On the other hand, qle} is taken to specify relocation of a pointer, even if 
the type of e is IndexType and not an appropriate relative pointer type. In such 
cases, the array must (and always can) be accessed by adding sufficient qualification, 
e.g., gt[e]; nevertheless, users should exercise caution in using pointers to arrays as 
base pointers. 

Mesa 4.0 supplies no mechanisms for constructing relative pointers. It is expected that such 
values will be created by user-supplied allocators that pass their results through a loophole 
or from pointer arithmetic involving loopholes. 

Examples 

pf ^ baseloffsetif 

p ^ baseloffset'] — valid pointer assignment (but often unwise) 

The following are invalid. 

p ^ offset; pt <r offsetf 

pLoffset'] has incorrect type 

Relative Array Descriptors 

Relative array descriptor types are entirely analogous to relative pointer types; indeed, values 
of such types can be viewed as array descriptors in which the base components are relative 
pointers. Note the following: 

In the constructor of a relative array descriptor type, the TypeSpecification must 

evaluate to a (possibly long) array descriptor type. 

In the notation introduced above, a reference to an element of the described array 
has the form 

baseloffset'lli'] 
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where / is the index of the element. 

Relative array descriptors are constructed using the descriptor operator. If p is 5 relative 
pointer, the form descriptorQ?, n, T] produces a value with type B relative descriptor for 
ARRAY OF T. Also, the operators base and length can be applied to a J? relative array 
descriptor; the former produces a B relative pointer. 

Block Structure 

The previous concepts of procedure body and compound statement have been merged. A 
block can appear anywhere a statement is acceptable and can introduce new identifiers with 
scope smaller than an entire procedure (or module) body. In addition, catch phrases and 
exit labels can now appear at the outermost level of a procedure body. 

The syntax for declaring procedures with bodies expressed in machine code has also been 
revised (in anticipation of more general inline procedures). The corresponding semantics 
are machine dependent and are not specified here. 

Syntax 

ModuleBody Block 

ProcedureBody ::s Block 

Statement ::= ... | Block | ... — replaces CompoundStmt 

Block begin 

OpenClause 

EnableClause 

DeclarationSeries 

StatementSeries 

ExitsClause 

END 

EnableClause empty | 

ENABLE Catchltem ; | 

ENABLE BEGIN CatchSefles END ; I 

ENABLE BEGIN CatchSefles ; end ; 

MachineCode machine code begin InstructionSeries end 

InstructionSeries ::= empty | ByteLlst | 

ByteList ; InstructionSeries 

ByteLlst Expression | ByteList , Expression 

In addition, the phrase classes Body, CompoundStmt and MachineCodeTC are deleted. 

During the execution of a Mesa program, frames are allocated at the procedure and module 
level only. Any storage required by variables declared in an internal Block (one used as a 
Statement) is allocaled in the frame of the smallest enclosing procedure or module. When 
such internal blocks are disjoint, the areas of the frame used for their variables overlay one 
another. 

The scopes of identifiers introduced in the various components of a block are summarized 
by the following diagram, where indentation is used to show the scope of each phrase: 
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BEGIN 

OpenClause 

EnableClause 

DeclarationSeries 
StatementSeries 
ExitsClause 

END 

Note that any newly declared identifiers are visible only in the DeclarationSeries and 
StatementSeries of the block. Any exit labels are visible within the EnableClause (as well 
as the more deeply indented constructs); on the other hand, any catch phrase in the 
EnableClause is not enabled within the ExitsClause. If the Block is used as a module or 
procedure body, the parameters and results are visible throughout the Block. Thus it is 
possible to open records designated by parameters or to assign return values within an 
ExitsClause (but the assigned values cannot involve internally declared variables). 

A CONTINUE statement appearing in the EnableClause of a Block causes exit from that block. 
A similarly placed retry statement causes reexecution of the block. In the latter case, any 
initializing values in the DeclarationSeries are recomputed. 

Note that an optional semicolon can now terminate a CatchSeries in an EnableClause. 
Nested Block Structure 

With the introduction of blocks, procedure bodies can appear where they were syntactically 
prohibited in previous versions of Mesa. Special rules apply to the inheritance of scope 
when a procedure body is declared within the DeclarationSeries or (with nesting) within the 
StatementSeries of a Block. Within the inner procedure body: 

Identifiers made visible by the OpenClause remain visible (unless redeclared). 

Catch phrases in the EnableClause are not inherited and not enabled. 

Identifiers declared in the DeclarationSeries remain visible (unless redeclared). 

Jumps to labels in the ExitsClause are prohibited. 

Assume the following skeletal declaration: 
Outer: procedure [...] = 

BEGIN 

ENABLE 5 => Handleriy, 

Inner: procedure [...] = begin ... end; 

EXITS 

Label => ... 

END 

If the signal s is raised in an instance of Inner, Handler is not invoked there. Handler will, 
of course, be invoked eventually if s propagates to the enclosing instance of Outer. (This 
noninheritance rule prevents double execution of handlers in such situations.) In Mesa 4.0, 
the statement go to Label is considered an error within the body of Inner. 
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Iterative Statements 

For consistency with blocks, the scope rules for iterative statements have been revised 
slightly. In addition, a new statement form that terminates one iteration of the loop body 
and initiates the next has been added. 

Syntax 

Statement ... | LoopCioseStmt 

LoopStmt ::s LoopControl 

DO 

OpenClause 
EnableClause 
StatementSeries 
LoopExitsClause 

ENDLOOP 

LoopCioseStmt loop 

The scopes of identifiers introduced in the various components of a loop are summarized by 
the following diagram (cf. Blocks): 

LoopControl 

DO 

OpenClause 

EnableClause 
StatementSeries 
LoopExitsClause 
ENDLOOP 

In previous versions of Mesa, the scope of the OpenClause excluded the LoopExitsClause. 
As in the case of blocks, any exit labels are visible within the EnableClause, and any catch 
phrase in the EnableClause is not enabled within the ExitsClause. 

The statement loop can appear only within the body of an iterative statement. Executing it 
terminates the current iteration of the smallest enclosing LoopStmt, after which the 
LoopControl is updated/reevaluated and, if appropriate, the next iteration is started. Thus 
the construct 

DO ... LOOP ... ENDLOOP 

is an abbreviation for 

DO 

BEGIN 

... GO TO Skip ... 
EXITS Skip => null; 

END 
ENDLOOP . 

Included Identifier Lists 

In Mesa 4.0, an item in the directory clause can explicitly list the identifiers eligible for 
inclusion from a designated module. Such included identifier lists serve as compiler- 
checked (but programmer-maintained) lists of intermodular connections and dependencies. 
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Syntax 

IncludeLlst Includeltem | IncludeList , Inciudeltem 

Includeltem identifier : from FileName | 

identifier : from FileName using [ IdList ] 

If the USING clause is absent, the item's identifier has all the properties and uses described in 
Sections 7.2.1 and 7.2.2. The only effect of a using clause is to enumerate (and potentially 
restrict) the set of identifiers made accessible to the including module. Use of the identifier, 
either within an open clause or for explicit qualification, makes visible only those 
identifiers in the IdList. 

Some fine pojnts. 

Only identifiers declared in the DeclarationSeries that is part of the ModuleBody of 

the included module are mentioned in the IdList; in particular, neither the included 
module's own identifier nor identifiers of record fields, enumeration constants, etc. 
appear in this list. 

Each identifier appearing in the IdList must be defined in the module designated by 
the Includeltem. 

A warning is generated for each identifier appearing in the IdList but not used 
explicitly in the including module. Identifiers used only implicitly (to describe 
attributes of explicitly included identifiers) should not be listed. 

The IdList restricts the set of identifiers available for inclusion from a module. It 
does not restrict export into an included interface. The identifier of an exported 
item should not appear in the list unless the intention is to reference a different 
item with the same name through an imported instance of the interface. 

The following example assumes the declaration of SimpleDefs appearing on page 92. 

DIRECTORY 

SimpleDefs: from "simpledefs" using [^Range, PairPtr'}; 
Example: PROGRAM = 
BEGIN 

First: PROCEDURE Ip: SimpleDefs, Pair Ptr'\ returns ISimpleDefsMangel = 

BEGIN 

RETURN [IF p = NIL THEN 0 ELSE p.first} 

end; 

END. 

Note that Pair does not appear in the included identifier list (because it is only 
referenced implicitly, through the definition of PairPtr), nor does first (because it is 
declared in a record, not in the body of SimpleDefs itself). Any reference to 
SimpleDefsJimit would be an error in this example. 

Processes 

Mesa 4.0 supports a process mechanism in which processes are created by forking to 
procedures and are synchronized by entry to monitors. Most of the information about the 
semantics and intended usage of Mesa processes appears in the Mesa 4.0 Process Update 
(henceforth cited as Process), The Mesa 4.0 Change Summary contains a complete example, 
and additional examples appear in the Process document. This section summarizes the 
syntax and deals with a few linguistic details. 
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Syntax 



PredefinedType 



I MONITORLOCK | CONDITION 



ProgramTC ::= 



MONITOR ParameterList ReturnsClause LocksClause 



LocksClause 



empty | 

LOCKS Expression | 

LOCKS Expression using identifier : TypeSpecification 



TypeConstructor 
ProcessTC ::= 



PROCESS ReturnsClause 



::= ... I ProcessTC 



Declaration 



IdList : Access EntryOption TypeSpecification Initialization ; | 
IdList : Access type = Access TypeSpecification ; 



EntryOption ::= empty | entry | internal 

RecordTC ::= MonitoredOption MachineDependent record [ VariantFieldList ] 

MonltoredOptlon ::= empty | monitored 

Statement ... | WaitStmt i NotifyStmt | JoinCall 

Expression ... | ForkCall | JoinCall 

WaitStmt ::= wait Variable OptCatchPhrase 

NotifyStmt notify Variable | broadcast Variable 

ForkCall ::= fork Call 

JoinCall ::= join Call 

Forking and Joining 

Processes are created and destroyed by fork and join operations. If procedure P has type 
PROCEDURE T RETURNS T\ then the expression fork P[...] produces a process handle h with 
type PROCESS returns T. join requires a process handle as its operand. The form join h 
produces an argument record of type T (or stands as a statement if the ReturnsClause is 
empty). As type mappings, 

fork: PROCEDURE T RETURNS T X T PROCESS RETURNS T 

join: PROCESS RETURNS T T\ 

Some fine points: 

A catch phrase can be attached to a fork or join (by specifying it in the Cai!). 

Unlike an ordinary procedure call, a fork returns a value with some process type 
(not a record type), and that value cannot be discarded by writing an empty 
extractor. 

Monitored Modules 

A ProgramTC containing monitor can be used only in a ModuleHead to specify the type of a 
program module. The LocksClause provides additional information about the program body 
and is not part of the module's type. If a monitor is to be exported, the correct type for the 
interface item in the definitions module is obtained by replacing monitor by program and 
deleting the LocksClause. 
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Synchronization of processes is based upon variables with the system-defined types 
MONITORLOCK and CONDITION. A distinguished monitorlock with the identifier LOCK is 
implicitly declared in the global frame of any monitor with an empty LocksClause. If the 
MonitoredOption monitored appears in the definition of a record type, each record of that 
type similarly contains an implicitly declared and distinguished monitorlock with identifier 
LOCK. Lock and condition variables can also be declared explicitly, but any monitorlock 
so declared is not distinguished, even if its identifier is LOCK (see below). 

When a variable with type monitorlock or condition is a component of a (local or global) 
frame, it is initialized automatically when the frame is created. In all other cases, a system 
procedure must be called to establish appropriate initial values (see Process, Section A.6). 

Entry Procedures 

The EntryOption entry can appear only in a declaration within a monitor; when it does, the 
TypeSpecification must evaluate to a procedure type and the initialization must specify a 
procedure body (Block). Note that entry does not imply public, but public entry is a 
permissible (and common) combination. 

Entry into a monitor through an entry procedure is protected by a monitor lock. The 
identity of that lock is determined by the declaration of the monitor. If the LocksClause is 
empty, entry is controlled by the distinguished variable LOCK Otherwise, the LocksClause 
must designate a variable with type monitorlock, a record containing a distinguished lock 
field, or a pointer that can be dereferenced (perhaps several times) to yield one of the 
preceding. There are two cases (see Process, Section A.4.2): 

If the USING clause is absent, the monitor is a multi-module one. The lock is located 
by evaluating the locks expression in the context of the monitor's main body; i.e., 
the monitor's parameters, imports, and global variables are visible, as are any 
identifiers made accessible by a global open. Evaluation occurs upon entry to, and 
again upon exit from, the entry procedure (and for any internal waits). The 
location of the designated lock can thus be affected by assignments within the 
procedure to variables in . the locks expression. To avoid disaster, it is essential that 
each reevaluation yield a designator of the same monitorlock. 

If the USING clause is present, the monitor is an object monitor. The lock is located 

as above with one exception: any occurrence of the identifier declared in the using 
clause is bound to that argument of the entry procedure having the same identifier 
and a compatible type. If there is no such parameter, the entry is in error. The 
same care is necessary with respect to reevaluation; to emphasize this, the 
distinguished argument is treated as a read-only value within the body of the entry 
procedure. 

The following examples illustrate the selection of locks. 

R: type = monitored record [...]; 

RR: type = RECORD [..„ sped a I Lock: monitorlock, ...]; 

ML' MONITOR = 
BEGIN 

— LOCK: MONITORLOCK implicitly declared here 

PL' PUBLIC ENTRY PROCEDURE [...] = 

BEGIN — locks LOCK — .,. END; 
END. 
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M2a: monitor [p; pointer to pointer to K] locks p = 

BEGIN 

P2: PUBLIC ENTRY PROCEDURE [...] a 

BEGIN — locks p'tf.LOCK — ... end; 

END. 

M2b: MONITOR Ip: pointer to POINTER TO RR} LOCKS pff.spccialLock s 
specification of the lock is mandatory here 

BEGIN 

P2: PUBLIC ENTRY PROCEDURE [...] = 

BEGIN locks p't'f.specialLock ... end; 

END* 

M3: MONITOR LOCKS p USING p: POINTER TO i? = 
BEGIN 

P3: PUBLIC ENTRY PROCEDURE [/?; POINTER TO R, ...] = 

BEGIN — locks p. LOCK — ... end; 

END. 

Signals require special attention within the body of an entry procedure. A signal raised 
with the monitor lock held will propagate without releasing the lock and possibly invoke 
arbitrary computations. For errors, this can be avoided by using the return with error 
construct described in the next section. 

When an instance of an entry procedure is to be destroyed because of a remote exit from a 
catch phrase (unwinding), the lock should also be released. In Mesa 4.0, it is the 
programmer's responsibility to determine if unwinding is possible and, if so, to provide a 
catch phrase for unwind that restores the monitor invariant. Code to actually release the 
monitor lock is automatically appended to the outermost enabled catch phrase for unwind in 
an entry procedure. That catch phrase can have a null body if no other cleanup actions are 
required. 

Internal Procedures 

The EntryOption internal can appear only in a declaration within a monitor; when it does, 
the TypeSpeciflcation must evaluate to a procedure type and the initialization must specify a 
procedure body (Block). Note that internal does not imply private (if the default is public), 
but PUBLIC INTERNAL is Considered an improper combination of attributes (warning only). 

A call of an internal procedure is permitted only within an entry procedure or another 
INTERNAL procedure. Forking to an internal procedure is never allowed. An internal 
procedure can safely access monitored data and can perform wait, notify and broadcast 
operations. A wait operation implicitly references the monitor lock; thus an internal 
procedure of an object monitor that contains a wait must have a parameter designating the 
locked object as described above. 

Some fine points: 

In Mesa 4.0, the attribute internal is associated with a procedure's body, not its type. 
Thus internal cannot be specified in a definitions module, and checks on 
intermodular calls of internal procedures are not performed (except for the public 
internal warning). Also, the attribute internal is lost when a procedure value is 
assigned to a variable or passed as an argument of a procedure. Such assignments 
should be done with caution. 



Mesa 4.0 Compiler Update 



17 



Signals raised by internal procedures require special consideration. When the 
construct return with error is executed within an internal procedure, the monitor 
lock is not released prior to signal propagation. 

Wait and Notify 

Only ENTRY and internal procedures within a monitor can contain wait, notify and 
BROADCAST Statements. 

Error Returns 

It is possible to delete a procedure instance before raising an error detected by that 
procedure. Within an entry procedure of a monitor, the monitor lock is released before the 
error is raised. (Such procedures are expected to be the primary users of this facility.) 

Syntax 

ReturnStmt ::= ... | return with error Call 

Consider the following skeletal code: 
Failure: ERROR [...] = CODE; 

Proc: ENTRY PROCEDURE [...] RETURNS [...] a 
BEGIN 

ENABLE UNWIND => 

IF condl THEN ERROR Fa//wre[...]; 

IF C0nd2 THEN RETURN WITH ERROR Fa//t/re[...]; 

end; 

Execution of the construct error Failurel...'] raises a signal that propagates until some 
catch phrase specifies an exit. At that time, unwinding begins; the catch phrase for unwind 
in Proc is executed and then P roc's frame is destroyed. Within an entry procedure such as 
Proc, the lock is held until the unwind (and thus through unpredictable computation 
performed by catch phrases). 

Execution of the construct return with error Failure^,..} releases the monitor lock and 
destroys the frame of Proc before propagation of the signal begins. Note that the argument 
list in this construct is determined by the declaration of Failure (not by Proc's returns 
clause). The catch phrase for unwind is not executed in this case. The signal Failure is 
actually raised by the system, after which Failure propagates as an ordinary error (beginning 
with Proc's caller). 

Multiword Constants 

Record and array constructors in which all components are themselves constant define so- 
called multiword constants. Such constants are now constructed during compilation and can 
be encoded within Mesa symbol tables. This has the following consequences: 

A declaration equating an identifier to a multiword constant (but not to a string 
literal) can appear in a definitions module, and the constant value thereby becomes 
available to users of that module. 
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Constant selection from such values (by field selection or by indexing with a 
constant subscript) is also done during compilation. 

Furthermore, if an identifier is equated to a multiword constant in a program module, 
exactly one copy of that constant appears in the code, and its components can be read 
(using, e.g., a computed index) directly from the code segment. This allows table driven 
programming in which the tables are automatically swapped. 

A fine point: A packed array or an array of multiword elements is currently copied 
into a data area each time one of its elements is accessed. 

The following declarations define multiword constants and can appear in a definitions 
module. 

Ident: RECORD Iversion: cardinal, id: character, released: boolean] = 
[1, false]; 

Powers: array [1..4] of cardinal = [2, 4, 8, 16]; 

Nonsense: cardinal = if Identjeleased then Ident.version else Powersliy, 
The following are not compile- time constants in Mesa 4.0. 
"abc", ("abc")Cl]. 

Miscellaneous Language Changes 

Local Strings 

The body of a string literal is ordinarily placed in the global frame of the module in which 
the literal appears. Pointers to that body (the actual string values) can then be used freely 
with little danger that the body will move or be destroyed. Unfortunately, this scheme can 
consume substantial amounts of space in the (permanent and unmovable) global frame area. 

If a string literal is followed by *L (e.g., "abc"L), a copy of the string body is moved from 
the code to the local frame of the smallest enclosing procedure whenever an instance of that 
procedure is created. As a corollary, the space is freed and the string body disappears when 
the procedure returns. Thus it is important to insure that pointers to local string literals are 
not assigned to string variables with lifetimes longer than that of the procedure. 
Programmers should avoid using local string literals until performance tuning is necessary 
(except perhaps in calls of straightforward output procedures). 

Character Arithmetic 

The following arithmetic operations are now defined for values of type character: 

character + integer character 
integer + character character 
character - integer character 

character - character INTEGER. 

Other arithmetic operations do not allow characters as operands, and values of type integer 
and CHARACTER cannot be cross-assigned. 

Examples 

c: character; 

d: INTEGER ^ c - *0; — consider a translation table instead 
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IF c IN ['a./z] THEN c 'A + (c-'a) 
Selections 

More general expressions are allowed to label arms of selections when there is no initial 
relational operator. 

Test ::= Expression | RelationTail — formerly Sum | RelationTail 

Example 

SELECT TRUE FROM 

/ > 0, y > 0 => sl\ — previously required (/ > 0), (/ > 0) 

p AND g => 52; — previously required {p and q) 

k > 0:OR q => s3\ 

ENDCASE => sN 

This is equivalent to (and perhaps more readable than) 

IF / > 0 OR > 0 THEN si 
ELSE IF p AND q THEN s2 
ELSE IF /: > 0 OR 9 THEN s3 

ELSE sN . 

Discriminations 

Previous versions of Mesa have required that all adjectives labeling an arm of a 
discrimination name identically structured variants; in Mesa 4.0, this restriction is lifted. If, 
however, the labels identify more than one variant structure, the record is not considered to 
be discriminated within that arm and only the common fields are visible (cf. endcase). 

Example 

R: TYPE = record [ 
v: r. 

variant: SELECT tag:* FROM 
red, pink => IvRP: T], 
green => [v(5; 7], 
yellow => IvY: Tl 

ENDCASE]; 

r: R\ 

WITH X: r SELECT FROM 

red, pink => ...; x.v and x.vRP accessible 

green, yellow => ...; only x.v accessible 

ENDCASE => ...; only x.v accessible 

Mesa 4.0 also allows computed or overlaid variant records to be compared without 
discrimination if all variants have the same length. As usual, caution is advised; two records 
interpreted as different variants can be represented by the same bit pattern when computed 
tags are used. 
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Compilation Options 

The following compiler options have been added; they are controlled by switches in the 
usual way: 

Switch Option Controlled 

alto Generating code for an Alto or Dstar 

run Terminating compilation by running another program 

sort Sorting global variables and entry indices 

The Alto/Dstar switch primarily affects the treatment of long pointers in the object code. 

The run switch specifies running another program without returning to the executive. This 
switch is primarily intended for use in command files. The file name preceding the switch 
specifies the program to be run. The file is assumed to contain a program requiring 
standard (Bcpl) microcode if the file name*s extension is ''.RUN*' and requiring Mesa 
microcode otherwise. The default extension is ".IMAGE". Prior to execution of the 
specified program, a new command file (COM.CM) is constructed containing the full file 
name plus any switches following the *r. In the case of command-line input, the remainder 
of the command line is also appended. 

The sorting switch has been added in anticipation of tools that will expedite updating a 
module in a configuration or subsystem when the new and old versions of the object code 
are sufficiently similar. When sorting is suppressed, the assignment of global frame offsets 
and entry indices depends only upon order of declaration in the source text; on the other 
hand, the generated code is likely to be somewhat less compact. 

Sorting of local variables is not suppressed. Unless a module uses global variables 
extensively, the object code expansion is unlikely to exceed ?%. 

The defaults are to generate code for an Alto, to terminate by returning to the executive, and 
to sort global variables and entry points. 

Internal Changes 

The following internal changes are mentioned for completeness; see the Mesa 4.0 System 
Update for more information. 

Main Body Procedure 

The main body of a module is now executed in a separate local frame. Note however, that 
any storage required by blocks or local strings in the main body is still allocated in the 
global frame. 

External Links 

External links (for imported procedures, signals or frames) are now stored and indexed 
backwards from the global frame base or code base (as selected by a binding/loading 
option). 
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Alto/Mesa Microcode 

Both the instruction set and the opcode numbers have changed substantially. 
Frame Allocation 

Instructions for allocating and freeing frames are now implemented in microcode; this 
greatly inceases the speed of any transfer involving a large argument record. 



Distribution: 
Mesa Users 
Mesa Group 
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Appendix: Signed and Unsigned Arithmetic 



Background and Overview 

In any implementation of Mesa, the number of bits available for representing a value of a 
given type is fixed. Each numeric type of the language thus is restricted to some subrange 
of Z, the set of integers as understood in mathematics. The following types, corresponding 
to the indicated subranges, are built into the language: 

INTEGER [-2^"^ 2^"^) — "signed integers" 

CARDINAL [0 2^) " "unsigned integers" 

LONG INTEGER [-2^^"^ 2^^"^) — "double-precision integers" 

Here N is the word length of the machine (A^=16 for the Alto and Dstar). The programmer 
can also declare types that are themselves subranges of cardinal or integer (but not LONG 

INTEGER), e.g., T: TYPE = [0..10), 

Let V, X, and y be variables with numeric subrange types. In principle, execution of the 
assignment v ^ x @ y proceeds as follows: 

The values of x and y are taken as elements of Z. 

Those values are combined using some function / that defines the operator 0 over Z 
and produces a result f(x,y), also in Z. 

If the result is in the subrange of Z spanned by the type of v, f(x,y) is assigned to v; 
otherwise a range failure occurs. 

Unfortunately, the underlying hardware does not provide the function / but only a partial 
function /' over some subrange of Z with the property that / agrees with / wherever both 
are defined; / is said to overflow (or underflow) elsewhere. In fact, the hardware generally 
provides a family of partial functions related to /, one each for integer, cardinal, and long 
INTEGER. The operator © thus is generic at the hardware level, and the compiler must choose 
the appropriate partial function for preserving the abstraction being used by the 
programmer (or for detecting its breakdown). The choice is made by considering an 
attribute of each operand called its representation. 

If the type of any operand is long integer, the rule is simple: all other operands are 
converted to long integer and the result is computed in that domain. For integers (with 
signed representation), cardinals (with unsigned representation) and subrange types such as 
T (with both representations), the issues are more subtle. Some operators, such as the 
relational, are clearly generic and were recognized as such in previous versions of Mesa. 
Many other operators produce the correct result modulo 2^ (i.e., the "right" bit pattern) no 
matter what representation is assumed; the representation affects only the definition of 
overflow. 

Examples (A^=16) 

The bit patterns representing -1 and 1777778 are identical, but (177777B > 1) is 
TRUE while (-1 > 1) is false . Also, (-1 + 1) = 0 and there is no overflow, but 
(177777B + 1) cannot be represented as an unsigned number. 

In a critique of Mesa [Wirth], Niklaus Wirth has argued strongly that the language should 
be defined so that the overflow condition can always be specified. Note that this is a 
necessary condition for implementing reliable range checking (also advocated by Wirth) but 



Mesa 4.0 Compiler Update 



23 



not a sufficient one. Mesa 4.0 does not provide options for overflow detection or range 
checking but does revise the language definition so that future versions can offer such 
options. 

While we have found no rules for mixing signed and unsigned values that are entirely 
satisfactory, we believe that those presented in the following section are reasonably 
unobtrusive, compatible with existing code and relatively free of surprises. 

Signed and Unsigned Numbers 

This section discusses the rules now used by Mesa for choosing between signed and unsigned 
versions of operations on single- precision numbers. The new rules assume that there are 
conversion functions performing the following mappings: 

CARDINAL INTEGER 
INTEGER CARDINAL . 

In both cases, the "conversion" amounts to an assertion that the argument is an element of 
INTEGER n CARDINAL. The programmer can also make such a range assertion explicit as 
described in the main body of this memo. In Mesa 4.0, such assertions must be verified by 
the programmer. There is not an option to generate code that checks these assertions, 
whether implicit or explicit, or code that detects overflow in arithmetic operations. 

For each of the operators +, -, *, /, mod, min, and max, there are two single-precision 
operations, mapping as follows: 

INTEGER^ -> INTEGER (signed arithmetic) 

cardinal" CARDINAL (unsigned arithmetic). 

Similarly, there are two operations for each of the operators =, #, <, <=, >, >« and in: 

integer" BOOLEAN (signed comparisons) 

cardinal" BOOLEAN (unsigned comparisons). 

There are no operations upon mixed representations in any case; thus all operands must be 
forced to have some common representation. The arithmetic operators also propagate that 
same representation to the result. 

A possible surprise is that cardinal is taken to be closed under subtraction; i.e., m-n 
is considered to overflow if m and n are cardinals and m < n. 

For any arithmetic expression, the inherent representations of the operands and the target 
representation of the result are used to choose between the signed and unsigned operations 
(cf. the discussion of inherent and target types, Section 3.1, pages 37-39). 

The target type determines the target representation. The target type is derived from 
the type of the variable to which an expression is to be assigned, from a range 
assertion applied to a subexpression, etc. If all valid values of the target type are 
nonnegative, the target representation is unsigned: otherwise, it is signed. The 
arithmetic operators listed above propagate target representations unchanged to their 
operands, but the target representation of an operand of a relational operator is 
undefined. Thus each (sub)expression has at most one target representation. 

The inherent representation of a primary is determined by its type (if a variable, 
function call, etc.), by its value (if a compile-time constant), or explicitly (if a range 
assertion). Possible inherent representations are signed and unsigned; in addition, 
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compile-time constants in [0 2^"^) and primaries with types that are subranges of 
INTEGER n CARDINAL are considered to have both inherent representations. Inherent 
representations of operands are propagated to results as described below. 

The basic idea is that generic operations are disambiguated first by the inherent 
representations of their operands, next by the target representation, and finally by a default 
convention. If the operation cannot be disambiguated in any of these ways, the expression is 
considered to be in error. The exact rules follow: 

If the operands have exactly one common inherent representation, the operation 
defined for that representation is selected (and the target representation is ignored). 

If the operands have no common inherent representation but the target 
representation is well-defined, the operation yielding that representation is chosen, 
and each operand is "converted" to that representation (in the weak sense discussed 
above). 

If the operands have both inherent representations in common, then 
if the target representation is well-defined it selects the operation; 
otherwise the signed operation is chosen. 

If the operands have no representation in common and the target representation is 
ill-defined, the expression is in error. 

In all cases, the inherent representation of the result is determined by the mapping 
performed by the selected operation. 

The unary operators require special treatment Unary minus converts its argument to a 
signed representation if necessary and produces a signed result abs is a null operation (with 
warning message) on an operand with an unsigned representation, and it yields an unsigned 
representation in any case. The target representation for the operand of long (or of an 
implied widening operation) is unsigned. 

Examples 

Assume the following declarations: 

/, 7; integer; ATI, n: cardinal; 5, [0..77777B]; b: boolean 

The statements on each of the following lines are equivalent 

/ ^ m+n; / ^ integer[/w+/i] — unsigned addition 

/ ^ y+/t; / ^ n-i-J; i ^ y+iNTEGER[n] — signed addition 

/ ^ 5+/; / ^ iNTEGER[5]+iNTEGER[r] — Signed (overflow possible) 

n 5+/; n ^ cardinal[s]+cardinal[0 — unsigned (overflow impossible) 

s 5-/; s <r cardinal[5]-cardinal[0 — unsigned (overflow possible) 

6^5-0 0; b ^ iNTEGER[5]-iNTEGER[r] > 0 — signed (overflow impossible) 

/ ^ -m; / ^ -integer[/72] 

/ m+n*(J-^n); i INTEGER[m] + (lNTEGER[w]*0'+'NTEGER[Ai])) 

n m+A2*0"+^); n ^ m ^ (a2*(cardinal[/]+ai)) 
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/ ^ / ^ INTEGER[m+(rt*(CARDINAL[5]+n))] 

6 ^ 5 IN b ^ INTEGERC^] in [lNTEGER[r-l] .. INTEGER[r+l]] 

FOR S IN ^+1] ...; FOR S IN [CARDINAL[r-l] CARDINAL[r+l]] ... 

The following statements are incorrect because of representational ambiguities. 
b ^ i > n; b ^ /+n IN [5 .. ;] 

SELECT / FROM m => t => ENDCASE 

Both the following are legal and assign the same bit pattern to /, but the first overflows if 
m<n. 

i mrn\ i ^ \f m >- n then else -(/i-m) • 
Reference 

Wirth, N. On the peaceful coexistence of integers and cardinals, Xerox PARC, 29 June 
1977. 



